Within the field of software design, object-oriented programming is a popular paradigm. The idea is that a software program may be seen as comprising a collection of individual building blocks, or objects, that act on each other, as opposed to a traditional view in which a program may be seen as a collection of functions, or simply as a list of instructions to a computer. A software object or building block, like a real life object, is capable of receiving messages from another object, processing data, and sending messages to other objects. In fact, a software building block can be viewed as an independent machine or actor with a distinct role or responsibility. Thus, a software program may be viewed as a collection of objects that interact with one another.
Because of the flexibility and maintainability that object-oriented programming offers, it is popular with large scale software engineering, such as network design. As these large scale software engineering projects are often highly complex and involves creating and managing numerous software building blocks, a number of management tools or “wizards” have been made to help software designers manage the software building blocks.
However, conventional wizards or management tools do not track or show created objects. Consequently, a software designer can lose track of what they are creating while working with the wizard. Moreover, conventional wizards do not provide software engineers with access to the created objects until the whole wizard is finished. As a result, details of a created object are not accessible during the design process. Furthermore, the relationships between the objects are not shown with existing wizards, making it difficult for a software designer to visualize the connections and/or interactions between different objects.
FIGS. 1A, 1B, and 1C illustrate a prior art network objects wizard in operation. FIG. 1A, corresponds to the first step of this process and illustrates a graphical user interface (GUI) of a network wizard 100. The wizard 100 includes a navigation panel 102, which shows a list of steps that a user takes. FIG. 1A also includes a back button 104 for moving to a previous screen, a next button 106 for moving onto the next screen, a finish button 120, and a cancel button 120. Furthermore, FIG. 1A includes a Name section 108, descriptions section 110, MPLS VPN setting section 112, use default value section 128, topology section 114, create default CERC section 130, a customer section 116, and a provider section 118. In this example, a user is to create a new virtual private network (VPN) by configuring VPN related attribute values. Also, the user adds Site to the VPN by configuring Attachment Circuit to join the VPN.
Referring now to FIG. 1A, user enters “Lahaina Storage” into the name section 108 and clicks the next button 106 to advance to the next step, illustrated in FIG. 1B. FIG. 1B corresponds to the second step of this process and includes navigation panel 102, add site option panel 126, and select site panel 124.
With reference to FIG. 1B, the user is advanced to the “Add site” step. In this step, a user can add a site to join “Lahaina Storage” VPN. In this step, internally “Lahaina Storage” VPN is configured with VRF and OSPF routing protocol. However, wizard 100 does not provide an object visualization means to reflect that “Lahaina Storage” VPN containing VRF and OSPF are build as output of step 1. After the user adds “Lahaina_Site30” to “Lahaina Storage” VPN, the user clicks on the next button 106 to advance to step 3, illustrated by FIG. 1C.
FIG. 1C corresponds to step 3 and includes an attachment circuit general panel 132 and a select a PE panel 134. Again, FIG. 1C of conventional wizard 100 does not visually reflect that in step 2, “Lahaina_Site—30” is added to “Lahaina Storage” VPN. In step 3, the user constructs the Attachment Circuit by selecting a PE for “Lahaina_Site—30” to connect. Here, the user connects “Lahaina_Site—30” to “Lincoln—01”. Again, the wizard 100 fails to provide visualization to the connection between “Lahaina_Site—30” and “Lincoln—01”.
With the conventional wizard 100, the user would continue on for the rest of the wizard steps without any means of visualizing the created network objects or the connections between the created network objects. As a result, the relationships and interconnections between network objects that have been built are obscure and hard to follow. Hence, the effectiveness of a network designer is negatively impacted by the lack of intuitive visualization means.